SD Times Issue 212 by BZ Media

Author:BZ Media
Language: eng
Format: epub
Tags: SD Times;
Published: 2008-12-14T16:00:00+00:00

support calls and rework later on.

It's a simple fact: When it comes to ALM tools, developers need training. But managers often assume developers are smart enough to figure everything out on their own; after all, isn't that what makes them good developers? And developers can make things worse by not asking for training, fearing that to do so would be an admission of weakness.

As a result, many developers learn to use a new ALM tool on the job, and that's a problem, for a number of reasons.

First, because they are focused on understanding the basics, novices aren't qualified to determine the best way to use a tool.

When you're learning to hit a baseball, you concentrate on simply making contact. You don't yet have enough knowledge to time your swing and hit the ball to the opposite field. The same idea applies to learning a development

LETTERS TO THE EDITOR

Women in IT

What a great article by guest columnist Lori MacVittie. In "Sexist and Offensive" [Nov 1, page 41]. She hit every point dead on. I couldn't agree with her more.

Activists are always looking for external factors that might explain why fewer women than men are in the IT world, yet they overlook the most obvious [reason]. Many women just aren't interested in IT. And success in an IT career demands that you really love the field.

I've been in IT for over 20 years, and I've seen the changes. In the '80s, there were virtually no women in IT During the '90s, there was a big push to get women into the field. It didn't work. Yes, more women got into IT for a while, but they weren't interested in the technology, did poorly, lost interest and left.

What we have now, in the 21st century, are women who are in IT because they love IT They perform just as well as men—and, in many cases (based on my recent experience), better.

Michael Adams

DATABASES ARE NOT APPS

I confess to knowing little about the specifics of frameworks such as the Java Persistence API ["SQL still serves," Nov 15, p. 38]. But as one who was comfortable with SQL long before learning any object-oriented language, I consider technologies that blend database definition and manipulation with application development tools to be curiosities. Beyond the similarity of eliminating

redundancy—OO development resembles normalizing code, much as database development normalizes data—I find little in common between the development of good databases and the development of good applications.

I have worked with nightmarish applications whose databases were designed solely from the perspective of the application developer, with little thought given to how the information in the database relates to itself or to the real-world entities it represents. What would prevent reliance on these blended tools from leading to the same scenario? Like roads and cars, databases and applications are largely useless without each other, but there is no reason to think that either pair can be developed and maintained optimally using the same tools.

I admit that bad embedded SQL isn't flagged by a compiler, but even Java code that goes through the compiler cleanly has to be tested.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.